REMARKS 

Claims 1-14 are pending the application. Claims 1-14 are rejected. New claims 15- 
24 have been added. No new matter has been added. Reconsideration is respectfully 
requested. 

Claim Rejections - 35 U.S.C. § 102 

Claims 1-14 are rejected under 35 U.S.C. § 102(b) as being anticipated by Lomet et 
al. (U.S. Patent No. 5,485,607). 

Claim 1 

A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference. Verdegaal Bros. v. Union 
Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987); MPEP §2131. 
Applicant respectfully submits that there are elements in the rejected claims which are not set 
forth in Lomet, therefore the rejections are believed unwarranted. 

However, claim 1 has been amended to further clarify the patentable subject matter. 
Claim 1 now specifies the first locking mode when first held on the data item determines an 
associated set of predetermined access restrictions for the data item and determines an 
associated different set of predetermined access restrictions for the neighborhood associated 
with the data item. Claim 1 also specifies the second locking mode when first held on the 
neighborhood determines the associated set of predetermined access restrictions for the 
neighborhood and determines the associated different set of predetermined access restrictions 
for the data item. 

This is clearly described in the specification at page 8, starting at line 4, and is also 
shown in FIGS. 7 and 8. For example, as described in FIG. 8 according to the table in FIG. 7, 
a first Sn lock transaction 50 on a data item C, allows a second Xnei lock mode for the insert 
transaction 52 for the free space associated with data item C. Similarly, as also shown in 
FIG. 7, if a Xnei lock mode is specified for the neighborhood associated with data item C, 
then a Sn lock mode would be allowed for subsequent transactions directed specifically to 
data item C. Conversely, a Xnei lock mode assigned by a first transaction to the free space 
neighborhood associated with data item C would create a second associated lock mode 



Docket No. 3222-004 Page 8 of 1 1 

Oracle Ref: OID-2005-333-01 



Application No. 10/671 ,297 



restriction that would prevent a second transaction from assigning a S lock mode to data item 
C. 

This locking scheme allows a first locking mode to be assigned to either a data item or 
its associated neighborhood, and then accordingly assign applicable different locking modes 
to the corresponding data item or neighborhood. 

Lomet 

Lomet does not describe a neighborhood locking system that restricts subsequent 
locking modes according to whether the data item or the associated neighborhood is already 
locked. Conversely, Lomet describes a locking system for dynamically redefining lockable 
ranges as key values are added and removed so that currently existing key values bound the 
currently lockable ranges. (Col. 10, lines 2-5). 

The Examiner refers to Lomet at column 9, lines 42-45 which states: 'The inserting 
transaction requests only an instant lock on kj +1 because there is no reason why one 
transaction's insertion of kf should prevent another transaction access to kj+i". The 
Examiner then suggests that kj+i is the tuple associated with the neighborhood, and as said in 
the reference, there is no reason for having to prevent access to it. 

However, there are reasons for preventing a transaction from accessing kj+i when 
another transaction is accessing kj. (Refer to page 8 and FIG. 7 in the present application) 
Accordingly, as specified in claim 1, a first lock mode assigned to a data item also restricts 
which second different lock mode can be assigned to the neighborhood associated with the 
data item. 

Lomet specifically teaches away from these limitations. There is no suggestion in 
Lomet of assigning a first locking mode to a first data item and then having that first locking 
mode determine what other locking modes can be assigned to the associated neighborhood by 
a second transaction. Lomet simply prevents a same lock mode assigned to k i+i from also 
being assigned to kj. Nowhere does Lomet suggest that a particular lock mode assigned to 
kj+i also restricts what different particular lock modes can be assigned to kj as specified in 
claim 1. 

When referring to FIG. 6, at column 8, line 56, Lomet states that the ARIES/KVL 
operation does not separately lock key values and key ranges and that FIG. 6 only shows the 
lock modes that would be required in the ARIES/KVL system. Nowhere does Lomet suggest 
that a first lock mode assigned to a data item restricts or controls what lock modes are 
available to the associated neighborhood for the data item as specified in claim 1. 
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Claim 10 

Claim 10 recites providing a first set of access privileges for to a first transaction 
accessing the data item and holding a lock mode on the data item corresponding with the first 
transaction; and providing a second set of access privileges to a second transaction operating 
independently of the first transaction and accessing for the neighborhood associated with the 
data item, the second set of access pri vileges determined by the lock mode already held on 
the data item by the first transaction. 

Lomet specifically teaches away from claim 10, For example, when discussing the 
Iln lock, Lomet states that first there is a determination of whether the range has a conflicting 
lock. If another transaction currently holds a lock on anything in the range ki to kj+i, 
including kj+i, the Iln lock is unable to modify anything in the range and the insertion can not 
take place. (Col. 13 In. 46-50). In other words, Lomet does not allow a first transaction to 
lock a data item and then allow a second independent transaction to access the neighborhood 
associated with the locked data item as specified in claim 10. 

Claims 2, 6 & 7 

Claim 2 has also been further amended to clarify a specific embodiment where the 
locking scheme allows a non-serializable scan of the data item with a first transaction while 
allowing a concurrent non-serializable lock on the neighborhood with a second transaction; 

allows a serializable scan of the data item with the first transaction while preventing a 
concurrent non-serializable lock on the neighborhood with the second transaction; 

allows a non-serializable lock on the neighborhood with the first transaction while 
allowing a concurrent non-serializable scan on the data item with the second transaction; and 

allows a non-serializable lock on the neighborhood with the first transaction while 
preventing a concurrent serializable scan on the data item with the second transaction. 
This is also clearly shown in FIG. 7, 

Conversely, Lomet does not even differentiate serialized and non-serialized 
transactions for data items and associated neighborhoods. 

Claim 6 specifies an (Xnei) mode that enables a first transaction to lock the 
neighborhood for inserting a new tuple but prevents the first transaction from locking a tuple 
associated with the neighborhood. 

The Examiner rejected claim 6 pointing to Col, 9 lines 42-45. However, that very 
paragraph states that there is an instant lock on the data item. Allowing an instant lock, no 
matter how short a duration, does not prevent a lock as specified in claim 6. 
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Claim 7 recites a database management system. . .wherein the Xnei mode enables a 
second concurrent transaction to modify the tuple while preventing the second concurrent 
transaction from having exclusive rights on the neighborhood. 

The Examiner rejects this pointing to Col. 9 lines 33-39 which discusses, first, 
inserting a kj+i record, and then afterward inserting a ki' record, where kC would have been in 
the ki+i neighborhood. It is clear that Lomet is not doing anything concurrently in this 
example. Further, it is clear that no lock is allowing the modification of k i+ i (which examiner 
asserts is the tuple for this case) while preventing the very transaction modifying ki+i from 
modifying the neighborhood (which would have to be k[' in examiner's example). 

Therefore Lomet does not teach a mode that enables a concurrent transaction to 
modify both the tuple while concurrently preventing the transaction from taking exclusive 
rights on the neighborhood. Similar arguments axe applicable to claims 8-9. 

For the reasons stated above, claims 1-9 are allowable under 35 U.S.C. § 102(b) over 
Lomet et al. (U.S. Patent No. 5,485,607), Claims 10-22 are allowable for the some of the 
same reasons 



For at least the foregoing reasons, reconsideration and allowance of claims 1-18 of the 
application as amended is requested. The Examiner is encouraged to telephone the 
undersigned at (503) 222-3613 if it appears that an interview would be helpful in advancing 
the case. 



MARGER JOHNSON & McCOLLOM, P.C. 
210 SW Morrison Street, Suite 400 
Portland, OR 97204 
503-222-3613 

Customer No. 20575 



CONCLUSION 



Respectfully submitted, 



MARGER JOHNSON & McCOLLOM, P.C. 




Stephen S. Ford 
Reg. No. 35,139 
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